feat(v1-usage): add credit-based Codex override windows#304
feat(v1-usage): add credit-based Codex override windows#304Daltonganger wants to merge 2 commits intoSoju06:mainfrom
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c440609427
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
app/modules/proxy/api.py
Outdated
| if max_value <= 0: | ||
| continue | ||
| current_value = max(0, min(int(round(summary.used_credits or 0.0)), max_value)) | ||
| reset_at = "" |
There was a problem hiding this comment.
If an upstream usage row has reset_at=None (which is a valid persisted state), _build_aggregate_credit_limits still emits a V1UsageLimitResponse with reset_at="". Consumers of /v1/usage that parse reset_at as an ISO timestamp can fail or mis-handle the window countdown for those rows. This should return a valid timestamp or omit/fallback the aggregate row when reset time is unavailable.
Useful? React with 👍 / 👎.
app/modules/proxy/api.py
Outdated
| async def _load_accounts_by_id(session: AsyncSession, account_ids: set[str]) -> list[Account]: | ||
| if not account_ids: | ||
| return [] | ||
| result = await session.execute(select(Account).where(Account.id.in_(account_ids))) |
There was a problem hiding this comment.
The aggregate credit window calculation loads accounts by ID without filtering status, so paused/deactivated accounts with historical usage can still contribute capacity and usage. In environments with disabled accounts, this inflates max_value and skews utilization downward for every API key calling /v1/usage, making limit signals inaccurate. Apply the same active-account filtering used in other proxy limit paths before summarizing usage.
Useful? React with 👍 / 👎.
2 participants
Summary
creditswindows (5hand7d) with a migration, schema updates, and API-key editor/display support/v1/usageto return aggregate credit fallback rows, preserve raw API-key limits as fallback, and mark rows with asourcefieldTesting
uv run ruff check app/db/models.py app/modules/api_keys/schemas.py app/modules/api_keys/service.py app/modules/proxy/api.py app/modules/proxy/schemas.py tests/integration/test_v1_usage.py app/db/alembic/versions/20260403_000000_add_credit_api_key_limit_values.pyuv run pytest tests/integration/test_v1_usage.pybun run lint -- src/features/api-keys/schemas.ts src/features/api-keys/components/limit-rule-card.tsx src/features/api-keys/components/limit-rules-editor.tsx src/features/api-keys/components/api-key-table.tsx src/features/api-keys/components/api-key-edit-dialog.tsx src/features/apis/components/api-key-info.tsxbun run typecheck